Before turning to the invention it is helpful to explain its background for better understanding. The field of the invention refers to the Transmission Control Protocol (TCP), which is one of the core protocols of the Internet protocol suite (TCP/IP). TCP provides reliable, ordered, error-checked delivery of a stream of bytes between programs running on computers connected to a local area network, intranet or the public Internet. Applications that do not require the reliability of a TCP connection may instead use the connectionless User Datagram Protocol (UDP), which emphasizes low-overhead operation and reduced latency rather than error checking and delivery validation.
TCP is a connection-oriented data transport protocol, meaning that two applications each running on a computer establish a session connection, before data can be exchanged. During session establishment also some protocol parameters may be negotiated. The data transport of a connection-oriented protocol like TCP is also reliable, meaning that lost data is retransmitted and that at the receiving end the data is delivered in the same order as it was sent by the sending application.
At the end of the data transfer, protocol elements are used to finish the session connection in an ordered manner. In contrast to TCP, UDP is a so called connection-less protocol.
A TCP/UDP/IP stack is part of a computer's so called networking stack, for example, part of Windows or Unix operating system, such as Linux. The TCP/UDP/IP stack is the piece of software which mainly handles the TCP/UDP/IP headers and builds the bridge between the computer's applications and the network interface.
A TCP stack terminates a TCP connection between two computers. In this context “termination” means that this is the endpoint of the TCP communication protocol. It does not mean close or end of the TCP connection.
An application software, running on a computer, communicates with the TCP/UDP stack using, for example, the Berkeley Sockets API (Application Programming Interface). The TCP/UDP/IP stack handles all network packets. These network packets can be sent and received over the public Internet and contain an IP header (e.g. defining the level version IPv4 or IPv6), a TCP/UDP header, and the payload data.
The application communicating with the TCP/UDP stack through the corresponding APIs does not receive the IP header or TCP/UDP header of received packets by the computer, but the payload data only. When sending data, only that data is given to the corresponding API function, while the TCP/UDP and IP headers are generated by the TCP/UDP/IP stack.
In the Berkeley Sockets API, used just as an example, the application uses initializing functions like “socket( )” and “bind( )”. The TCP function “connect( )” is called to establish a connection to the other computer. To send data, the TCP function “send( )” is called, while the TCP function “recv( )” is called to receive data. Depending on the operation system, some type of a TCP function call of “close( )” is called to shut down a connection.
The TCP stack has the functionality that an application can switch between blocking mode and non-blocking mode. When blocking mode is used, the called API functions return only at the time when the TCP stack has done the required work. When non-blocking mode is used, all API function calls return immediately, but some mechanism is used so that the application is notified when the socket operation has completed. More sophisticated applications use non-blocking mode.
TCP is used widely on the public Internet, for example, for Web browsing. UDP is the preferred protocol for telephony communication, such as Voice over IP (VoIP).
On networks like the public Internet, when there is too much traffic, network packets are silently discarded. This is a very important feature of the Internet Protocol (IP), as this Internet protocol is not connection-oriented. If the Internet would use a connection-oriented protocol, such as the base application data transport protocol TCP, it would not be able to handle all the huge number of data packets sent through today's public Internet.
When on a TCP connection a packet is lost, the sending TCP stack does not get the acknowledge it waits for during a certain time, so it sends the lost packet again.
Of course, when packets are lost and are re-sent after a certain time, the number of data packets effectively sent over a TCP connection within a given period of time is much less compared to the possible maximum, so the connection gets slow and the overall speed suffers.
Further on a TCP stack, when sending packets, cannot send packets as fast as the speed of the connected communication line would allow. This would result in too much packet losses. Instead, a TCP stack starts slowly and monitors the connection to the partner computer. This mechanism is called “slow start”.
When no packets are lost, the speed is increased. When packets are lost, the speed is reduced to a starting value. This happens all the time while data is sent over a TCP connection.
TCP stacks also implement the functionality of flow control. Flow control means, when the sending application tries to send data faster than the receiving application (on the other computer) receives and processes the data, the sending application is blocked, so it needs to wait.
This blocking of the sending application is done by means of the receiving TCP stack on the other computer. It still acknowledges the received data, but it sends a TCP status information which is called “zero window”, notifying the sending TCP stack that it cannot receive more data at the moment.
Further on TCP connections are established by a so called “three-way handshake” between the two TCP stacks. This works as follows:
The TCP stack which wants to establish the connection with an application on a remote computer sends a TCP packet with the SYN bit set (synchronize sequence numbers) in the flags (control bits) of the TCP header (SYN packet). The remote TCP stack answers with SYN and ACK (acknowledgment) bits set in the flags of the TCP header. Then the first (client side) TCP stack sends an acknowledge (ACK) packet to finally establish the TCP connection.
When on the remote side no application is listening for the destination port in the first incoming TCP packet with SYN, the TCP stack answers with RST (reset the connection) so that no connection is established.
It may also happen that a client computer's TCP stack sends a SYN packet to an Internet address where there is no computer or the computer is not online. In this case, there is no answer to the SYN packet, and there is a timeout since no session can be established.
Fully transparent network access providing Virtual Private Network (VPN) tunnels can either use TCP or UDP as the transport layer protocol. They can also use other, non-connection-oriented, protocols, like IPsec (Internet Protocol Security), which in turn can also use UDP (User Datagram Protocol/NAT-T), ESP (Encapsulating Security Payload) or AH (Authentication Header).
When VPN tunnels use TCP as transport layer, the security protocol used is usually SSL (Secure Sockets Layer) or TLS (Transport Layer Security). In some implementations, SSH (Secure Shell) is used.
There are advantages and disadvantages when using TCP as connection-oriented protocol versus any other of the connection-less protocols.
Following advantages of TCP when used as a VPN tunnel protocol are worth to mention:                TCP can mostly be used because it is not blocked by firewalls in hotels or hotspots. Firewalls need to allow TCP connections, namely e.g. TCP port 80 for HTTP and TCP port 443 for HTTPS because otherwise the users could not browse the Web.        The data stream of TCP connections can be compressed far better as compared to connection-less protocols. When during a TCP connection a packet is lost, it is re-sent, and so a dictionary for compression (which needs to be identical on both sides) always has the correct content. In fact it is not possible, or at least not so easy and efficient, to use dictionaries for compression of multiple packets on connection-less protocols, since packets always can be lost in between.        
Now the disadvantages of the TCP protocol when used as a VPN tunnel protocol are the following:                There may be TCP meltdown. TCP connections inside the TCP VPN tunnel get slow since, due to the nature of the TCP stack, the inner TCP stack will not always send data when the outer TCP tunnel could send data.        TCP is not well-situated for real time streaming applications such as audio (voice over IP) or video (movies). The reason is that when a packet of a connection-less protocol is lost from the real time stream, on the receiver side there is only a short disruption, nothing more. The lost packet is not re-sent and the user still can hear and understand the audio or video. When a packet of a TCP connection is lost, the sender does not get an acknowledge, it waits a certain time and sends the packet again.        
All this results in a significant interruption of the data stream to the receiver leading e.g. to a perceivable disturbance of the audio reproduction on the receiver side.